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(57) Abstract: An online machine data collection 
and archiving process (15) generates a machine data 
profile (18) of a customer computer (5) accessing a 
transaction form of a merchant web site (3) and links the 
machine data profile (18) and a transaction record (6) 
with customer identifying information using a unique 
transaction identification string. The process preferably 
captures parameters typically communicated as pait of 
web accesses, such as an IP address, an HTTP header, 
and cookie information. The process additionally causes 
the customer computer (5) to process self-identification 
routines by processing coding within the merchant 
transaction form, the self-identification routines 
yielding further profile parameters. The process further 
includes a routine for bypassing an intervening proxy 
to the merchant web site (3) to reveal the true IP address 
of the customer computer (5). 
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1 ONLINE MA.GHINE DATA COMJECnONAlWARCHim 

2 

3 Cross-Reference to Provisional Application 

4 Tiiis appfication claims benefits fi'om provisional application. Serial No. 

5 60/209,936 filed June 7, 2000 and entitled METHOD FOR COIIJBCTINGMACHINE 

6 DATA FROM CUSTOMERS ON A COMPUTER NETWORK. 

7 

8 Background of the Invention 

9 The present invention rebtes to identity detection techniques and, more 

1 0 particulady, to a process for collecting and utilizing machine-identi^dng data of computers 

1 1 and other online appliances used in online interactions and transactions and assodating the 

12 collected machine data with such online interactions. 

1 3 The internet, or global conq>uter netwoil; represents a new medium fi>r mariceting 

1 4 similar to the way mail ordering and telephone ordering did in the past A downside of 

15 int^et mariceting is that it also presents new opporbmities for unscrupulous persons to 

1 6 take advantage of the mechanisms of sntmiet transactions by firaudulent and deceptive 

1 7 practices. Merchants and financial institutions bear the initial costs of firaud. However, 

1 8 consumers ultimate^ pay the costs in the form of prices and credit rates winch must take 

1 9 into account losses firom firaud. Internet purchases typically mvolve the use of web page 
2 0 forms which are filled in by the customer with identity, address, purchase, shippii^ and 

1 



wo 01/97134 



PCTAJSOl/18076 



1 payment infonnation and submitted to the online merchant f^^ Internet 

2 purdiases are most often paid for by way of credit cards. While a merchant's software 

3 may be able to verify the existence and status of a credit caid account number and an 

4 authorization for a specific amount, the merchant is often not able to match a credit card 

5 munb«- with a spedfic purchaser or shipping address. Thus, absent aiqr overt indication 

6 otherwise, a merchant generally assumes that anyone usii^g a credit card is authorized to 

7 do so and that a customs- is vHao he identifies hunsdf to be. 

8 An important st^ in combatimg fi^aud is accurate identification of the con^uters 

9 through whidi customers make transactions and associating such identities with 

1 0 transactions which arouse suspicions or which ultimately turn out to be ftaudulent Basic 

11 madiineidentityisessentialtothemfflmerinwhichtheintemetopa^. Wespeakin 

12 terms ongoing" to a web site. In reali<y,«going^ to a web dtemvolves sending a request 

13 for a web page file in a dhwtoiy or foldo- on a computer located at a spedfic internet 

14 protocpl, or IP, address. In order for the web page file to be returned to the requesting 

15 computer for processmg into a displayed "web page", the request must include return 

1 6 "directions" in the form of the basic identity of the requesting computer, including its IP 

17 address. Some web sites are implemented with software which enables responses to web 

18 page requests to be taflored to specifics of the requesting niachine's configuration, spedfic 

19 web browse, and the like. For this reason, current versions of browsers usually 

2 0 communicate configuration information in addition to a i«tum IP address and return patiL 
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1 The IP address of a page requesting computer can give an indication of the specific 

2 country where the computer is located. * Further, identification of a page-requesting 

3 computer can also recogmze a returning user u^g the same computer as during a 

4 previous access. For example, placing an HTTP (hypertext transfer protocoQ "cookie'' on 

5 a page-requesting computer can make it possible to identify the conq>uter on a later 

6 access. 

7 Because duBctint^Bction with a customer's computer is essratial in d^^ 

8 firaud, it has been assumed that any viable firaud detection software must be integrated with 

9 a merdiant's software. As a result, most e?dsting fiuud detection solutions require 

1 0 merchants to either abandon or extensively modify their existing web-based transaction 

1 1 processing software. An additional problem with fdcusmg fi:aud detection at single 

12 merchants is that peipetrators of fiaud often hit many merchants in an attempt to avoid or 

1 3 delay detection. Thus, an ideal system for fi^ud detection in online marketing would only 

1 4 nuninially affect the merchant's existing software and would route fi^d detection efiEbrts 

1 5 through a central, third-party entity serving a large multitude of merchants. 
16 

17 Summary of the Invention 

1 8 The present mvention provides a process for coUec^g data assodated with a 

1 9 customer's computer during access of a merdiant, finandal, other host web site, and 

2 0 assodating a transaction identification number v^h the data and with a transaction form of 

21 the merchant. Generally, the present invention captures machme identifying data from a 
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1 computer or other digital appliance accessing a host web site, sends the captured data to a 

2 madiine data archive along with a unique transaction idartificatiott string for storage in the 

3 archive and writes the same transaction identification string into a transaction form 

4 through which transactions with the host wd) site are conducted. The machine data is, 

5 thus, assodated with the customer identification data within the transaction form by way 

6 of the transaction identification string and can be used on-the-fly or at a later time for a 

7 variety ofpuiposesindudii^g, but not limited to, fiaud detection. Afthoughthetemi 

8 "aidiive" is used, the madiine data collected need not be stored pennanently. 
The machme data collection process of the present mvention is intended to be 

employed in a variety of applications induding, but not limited to: online purchases and 
orders; onlme banking, bill p^ent, and fiinds transfers; online r^istralions, sudi as for 
memberships, product warranties, ^plications for credit rraewal of subscriptions and 
licenses; online technical support; and the like. The term "transaction" is used in the 
present invention to describe an interaction eSbcted between a digital ^liance and a host 
system. However, the term ''transaction'' is not mtended to be restricted to only 
commercial interactions invohong purchases. The term "transaction" is mtended to apply 
to an interaction of a remote digital appliance with a host system using a rdativdy 
anonymous type of access process over a d^ medhnn ki'which some form of self- 
identification of the accessing appliance is inherent in the access process and in whidi the 
true identity of the accessiqg parly, the true source address of the appliance on the 
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1 medium, and/or the true machine characteristics of the accessing appfiance is/are essential 

2 or desirable to the interaction. 

3 The host entity \^ch operates the host system accessed is intended to enconqpass 

4 a commercial, financial, educational, governmental, assodational, or other type of entity. 

5 The term 'Merchant" will be used h&cdn to ref^ to such a host entity without mtent to 

6 limit the present invention to commercial transactions. The medium of access is intended 

7 to be interpreted as including a global computer network such as the internet or world 

8 Tvide web, as well as other types of networks which may be less than global but which are 

9 publicly and/or anonymously acc^sible. The term ^interaef will be used herein to refer 

10 to the medium through which accesses to the host entity are made. The terms "customer 

11 computer*' or "machine" are used herein to refer to a device for effecting remote access to 

12 a host system over a digital mecfium and are meant to encompass not only conventional 

1 3 types of phonal computers, but also additional types of "digital appliances" with online 

1 4 access capabilities, such as: cdl phones, personal digital asdstant devices^ electronic game 

1 5 systems, television sets with online access capabilities, web appliances for vehicles, and 

1 6 any other type of device witii online access capabilities whether connected to a wired 

1 7 communications network directiy or by a radiant technology. 

1 8 The machine data collection process of the present invention contemplates a two 

1 9 party process embodiment in which a ^merchant" processes and/or stores madiine data 
2 0 profiles of customer computers in-house, as well as a three party process embodiment in 
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whidli machine data profiles of customer computers are processed and/or stored for the 
mot^iant by a third-pat^ madiine data collection and atdiive service. 

Li a two party embodiment of the data collection process of the present invention, 
the customer madiine data is captured by a merchant or host system which also generates 
a unique transaction identification (ED) string and assigns or associates the transaction ID 
with a madiine data profile of the customer machine data profile. In the two party 
process, tiie merchant system captures cu.stomo' computer data which is inheientty passed 
fix)m tiie customs compute to the merchant's web sit^ such as an IP address of the 
cus^mer computer and an BTTP header. Additionally, according to the present 
invention, the merchant web page code may have routines or calls for external routines 
i;^ch, wfa^ processed by the customs con^uter, cause the customer computer to 
fiirth^ identify itself by collecting and returning certain machine and sofitware 
conifiguration duoacteristics, vrbada. can be used to id^itify the particuhr customer 
computo-. The two party process may indude the gen^^on and setting of an HTTP 
cookie in the customer browser for recogmtion upon a later access with the merchant web 
site. 

Although the two-party ^bodiment of the machine data collection process of the 
present invention has utility for some applications, the three party embodiment is preferred 
for applications in which analy^ of a nuudmum number of customs compvAer profiles is 
desirable, sudi as certain types of madceting processes and fimid detection and control 
processes. In a three embodiment of the present invention, the customer machine data of 
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1 computers accessing the second party or merchant web site is conununicated to and stored 

2 within a third party system, referred to herdn 4S a machine data archive service. In the 

3 three party process, the transaction ID could be generated by the merchant system, but is 

4 preferably generated by the archive service. The use of the term ''archive'' is not meant to 

5 indicate that the customer machine data profiles are stored permanently within the third 

6 party system. Permanent storage of such profiles may not be practical, as &r as yieldmg 

7 beneficial results to the purposes for which the profiles are collected. Thus, the term 

8 "^archive" is meant to indicate a central storage &cility, such as a database, with a selected 

9 retention period, with purging of most profiles after a obtain length of time. 

10 In the three party process a routine or line of code is added into the hypertext 

1 1 markup language ^flML) code whidi defines the merchant's web page, particularly an 

1 2 order or transaction form page* The added routine issues a request for a machine data 

1 3 collection (MDC) script to the third-party web site when the form page code is processed 

14 by the custom^'s browser. When the script request is received by the machine data 

1 5 archiving service (MDAS), the archive service generates a imique transaction 

1 6 identification (TA/DD) and checks for its own cookie. If no MDAS cookie is present, the 

17 archive service sends a cookie to the requesting computer along with a machme data 

1 8 collection (MDC) soript having the transaction ID embedd^ therem. The MDC script is 

1 9 executed by the customer's browser, causing collection of certain data firom the 

2 0 customw's computer which is sent back to the archive s^ce along with the transaction 

21 ID and stored in a machme data profile in the machine data archive. The transaction ID is 
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written into the transaction form, and when the transaction form is submitted to the 
merchant web site, the transaction ID string becomes a part of the transaction data record, 
along with customer identification, location, and financial information. 

Hie machine data initially collected and stored m each profile preferably includes 
the transaction ID, the apparent IP address of the customer's computer, a conventional 
HTTP header vMoh identifies the customer's browser versions and certain configuration 
aq>ects of the browser, and the archive service's cookie. The combination of such 
information, minus the transaction ID, will be relatively rare but may not be unique. 
Additionally, customers intent on conducting fiaudulent transactions often hide thdr IP 
address behind HTTP proxies. In order to fiirther narrow the machme profile, in a 
preferred embodiment of the pres^ invention, the MDC script performs additional 
machine profiling operations: generation of a machine **fingerprinf ^ and a pro^g^ 
"pierdng" op^ation. 

In the fingerprint generation operation, the MDC script assembles an attribute 
string formed by various attributes or configuration settings of the browser whidi can be 
queried by the script. The MDC script then performs a conversion process on the 
attribute string to generate a fingerprint string having content which is a fimction of the 
original cont^ ofthe attribute string. The conversion probess is prefi^ty a "^hashing" 
fimction wMch is, in effect, an in-ev«rsibleenciyptionaIgorit The generation of a 
conventional checksum is one exaasph of a ^e of hashing fimction. For example, if the 
attribute string is formed by alphanum^c charactm, the conversion process is performed 
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1 on the string of codes representing the characters. The particular conversion process or 

2 hashing fiinction used may be one ot rmsy typ^s of conventional conversion algoritiims or 

3 hashmg functions, which are typically used for data integrity tests. The resulting string 

4 from the MDC conversion process is a so-called fingerprint, which is retumed to the 

5 archive sovice along with the transaction ID for storage in the machine profile. A time 

6 value, queried from the customer computer time-of-d^ clock, is retumed with the 

7 fingerprint string and stored m conjunction therewith. 

8 An HTTP proxy is one of several types of proxies through which a browser may 

9 be setup to operate. Setting up an HTTP proxy causes HTTP requests to be rdayed by a 

1 0 primary gateway, through which the computer actually interfaces to the internet, to a 

11 remote secondary gateway, or proxy, with an IP address different from the primary 

12 gateway IP address. Such redirection hides the true IP address of a computer. The proxy 

1 3 pierdng operation of the MDC script queries the customs computer for any LAK (local- 

1 4 area network) address which may be assigned to the computer and reads the system time 

15 of day clock. Then attempts are made to send the LANT address, if any, the time value, 

16 and the transaction ID to the archive service using a protocol which will not be redirected 

1 7 through the HTTP proxy, for example a lower level protocol such as TCP/IP or UDP 

1 8 protocols. If the attempt is successfiil, the message contaii£mg the time value, the 

1 9 transaction ID, and IAN address arrive at the archive service web site with the Ime return 

20 IP address of the customer compute, whether an HTTP proxy interv^es or not The 

21 lAbT address and IP address so derived are stored mtiieina(^e^^ It should be 
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noted that the use of an HTTP proxy is not, of itsd^ an indication of fraud. However, the 
acquisition of an additional IP address is one more parameter with which to identify a 
particular computer. 

When, and i^ the customer submits the transactira form to the merchant, the 
transaction ID striog is communicated to the merdian^ along with other customer 
infimnation such as name, adch-ess^o^edit card nuniber and tte like phis transacticm 
information. The complete transaction record is stored on the merchant's syston and is 
associated with a spedfic madiine identity profile within the archive service by way of the 
transaction ID string. Iliereafta^, the stored machine identity profiles and transaction 

records of large numbers of transactions can be analyzed by various fimid detection 

techniques to detect patterns of fraud and fraud attempts anc^ preferably, identify and 

locate the som-ces of sudi activity. 

The madune data profiles stored in the arduve service need not be combined with 

the customer identification information for non-suspidous transaction^ to thereby 

preserve the privacy cfnon-suj^dous customo^s withhi the madiine data archive. 
£fowever, die processes of the preseat mvention do not lequhe that the customer 
identification infisrmation be kept separated from any assodated machine data profile^ and 
theare may be reasons to combme the assodated records. 
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1 Brief Description of the Drawings 

2 Fig. 1 is a simplified block diagram illustrating a plurality of customer and 

3 merchant computers interfaced to the intemet along with a machine data archiving service 

4 computer for practicing the machme data collection process of the present invention. 

5 Fig. 2 is a simplified block diagram illustrating connection of a customer computer 

6 to the internet, with optional components shown in phantom lines. 

7 Fig. 3 is a flow diagram illustrating piindpat steps of the machine data collection 

8 and archiving process accordmg to the present invention. 

9 Fig. 4 is aflow diagram illustrating more detailed steps of the machine data 

1 0 collection and archiving process according to the present invention. 

11 Fig. 5 is a flow diagram illustrating a stittfiuther detailed steps in the machine data 

12 collection and archiving process of ibe present invention. 

13 Various objects and advantages of this invention will become apparent fi^om the 

1 4 following description taken in rekition to the accompan^g dravdngs v^erdn are set 

1 5 forth, by way of illustration and example, certain embodiments of this invention. 

16 The drawmgs constitute a part of this specification, include exemplaiy 

1 7 embodiments of the present invention, and illustrate various objects and features thereof. 
18 

19 
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Detailed Description of the InventiQn 
As required, detailed embodiments of the preset inveotion are disclosed herein; 
however, it is to be understood that the disclosed embodiments are merely exemplaiy of 
the invention, which may be embodied in various forms. Therefore, specific structural and 
fimctional details disdosed herein are not to be interpreted as limiting but merely as a 
basis for the daims and as a representative basis for teaching one skilled in the art to 
variously ^ploy the present invention in virtually any appropriate^ detailed structure. 
Referring to the drawings m more detail: 
The refermce numeral 1 (Fig. 3) generally designates 
a process for online collection of machine identifying or profiling data of computers 
involved in commerdal transactions and for archiving such data to fedlitate analysts for 
fimid detection purposes. The process collects madiine identifying or profiling data of 
conq>uters involved in commerdal transactions and archives such data in a tiurd-party 
machine data archive s^ce in assodation with a transaction identification string or ID 
which is also vmtten into a transaction fi^rm of a merchant with whom the oistomer is 
conducting a transaction. 

Fig. 1 illustrates a plurality of host entities or merchants with corresponding 
merchant computers 2, on which are operated merchant web sites 3 i?^di are accessible 
over a global computer networl^ such as the intemet 4, by a plurality of customer 
computers 5. The merchant computers 2 execute various programs whidi liable the sale 
ofproductsors^cesbywayofth6int^et4. The merchant wd) sites 3 typically make 
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1 use of form type web pages with which the customers 5 interact by filling in various data 

2 fields, for example, name, address, shipping address, telephone number, credit card type 

3 and number and e)q)iration date, and description and quantities of products to be ordered. 

4 The merchant transaction forms are usually written in hypertext markup language 

5 (HTML) and may include requests for code written in other languages, such as Java and 

6 the like. When a customer 5 accesses a merchant's transaction form, a transaction form 

7 file is communicated to the customer's computer with various data fields displayed as fill- 

8 in boxes or the like. The customer fills in the appropriate fields and selects a submit 

9 "button" which activates a routine to transfer the collected information back to the 

1 0 merchant web site 3 for processing. The returned "form" is a data record 6 which is 

1 1 stored in a merchant transaction database 7 for retrieval and processing in due course to 

1 2 cause the ordered items to be gathered, packaged and prepared for shipment, along with 

1 3 financial processing to debit the customer's credit accoimt. The finandal processing may 

1 4 include a validity check of the credit account and an authorization check for tiie amount of 

1 5 purchase with the credit card issuer. Additionally, inventory management processes are 

1 6 executed based on the items withdrawn fi-om stock for shipment. 

17 In a three party embodiment of the present invention, the process 1 makes use of 

18 an entity referred to herdn as a machine data archiving service, MDAS or archive service, 

1 9 which operates an archive service computer system 15, including an archive service web 
2 0 site 16. The archive service system IS maintmns a machine data archive service database 
21 or ardiive 17 in which the machine data collection profiles^ 18 fi-om customer computers 5 

13 
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1 of the merchants 2 are stored. The archive service web site 16 is intet&ced to the internet 

2 4. The archive service IS is preferably indep^dent of the merchants and may be operated 

3 by a merchants' association^ a financial institution or association thereof or may be an 

4 independent contractor. Alternatively, it is conceivable that a merdiant with a lugh 

5 volume of online sales could operate its own in-house machine data profile collection and 

6 archiving service IS, for fraud detection or pos^bly fbr marketing purposes. 

7 Referring to Fig. 2, a customer conq>uter syst^ S includes a customer computer 

8 20 inter&ced to the internet 4 by way of a prhnary gateway 22, as of an int^et service 

9 provider (ISP), llie computer 20 might be one ofmany on a local area network or LAN 

10 24 which includes a router or switch vsdiich routes data fi-om the internet 4 to the 

1 1 con^uters on the network. The.computer 20 may communicate througfh the internet 4 by 

1 2 way of a HTTP (hypertext transfer protocol) proxy 26, which disguises the internet 

13 protocol (IP) address ofthe actual gateway 22. The computer 20 accesses web ^tes on 

14 the internet 4 using a customer web browser 28 which processes BTML language and 

1 5 various other standard wdb oriented languages to display or otherwise render tilie cont^ 

1 6 of wd) pages and interact therewith. The browser 28 is normally enabled to accept 

1 7 "cookies" 30 which are stored in a cookie file. Cookies 30 are data strings which are 

1 8 issued by Web sites and give an indication of a previous vi5^ to a paiticular web site and 

1 9 may indicate a particular configuration or set of preferences ofthe customer's setup ofthe 
2 0 compute 20. Typically, the customer conq>ut^ 20 has a time of day dodc/calaidar 32. 
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1 The customer computer 20 may have a fixed IP address, depending on the maimer 

2 m which it is mter&ced to the mtemet. More commonly, the customer computer 20 will 

3 have a temporary or dynamically assigned IP address which is detenmned by the primary 

4 router22. Theprimaryrouter22hasanff address, asdoarouterofaLAN24oran 

5 HTTP proxy 26 if either is present in the customei's computer system 5. 

6 Fig. 3 illustrates the prindpal actions or steps of a general or basic process 34 of 

7 the process 1 for coUectixig machine identifying data from customer computers 5. At sib&p 

8 35, at least one machine identifying profSe parameter is captured upon access of a 

9 customer computer S or other online access device with a host or merchant web Ate 3. A 

1 0 umque transaction identifier or TA/ID is generated at 36 and associated at 37 with the 

1 1 captured profile parameter. The transaction ID is also assodated at step 38 with a 
^12 transaction record generated as a result of the mteraction or transaction conducted 

1 3 between the customer computer 5 and a merchant web site 3 . Although not specifically 

1 4 shown in Fig. 3, the process 34 may capture machine profile data tiiat is passed firom the 

1 5 customer computer 5 to the merchant computer 3 as an inherent step of the customer 

1 6 compute 5 accessing the merchant computer 3. Alternatively, the process 34 may pass 

1 7 routines to the customer computer 5 to cause it to ''self-identify'' itself by querymg certam 

1 8 configuration paramet^ and passing such information to a machine profile stored dtiier 

19 within the merchant's system 2 or in a third party archive 17. The process 34, thus, 

2 0 encompasses a two-party embodiment or a three party embodiment of the machine data 

2 1 collection and archiving process 1 of the present invention. 

15 
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1 Referring particularly to Fig. 4, a more particular three party embodiment of tiie 

2 machine data collection and ardiiving process 1 b^ins at step 40 with the coding of a 

3 machine data collection (MDC) script request into the web page code for a transaction 

4 form of a merchant web ^e 3 . When a customs 5 accesses the merchant transaction 

5 form at step 42, the customer browser 28 processes tiie transaction page code, inchiding 

6 the MDC script request, which causes the MDC script request to be communicated to the 

7 ardiive service web site 16 at step 44. The script request arrives at the archive service 15 

8 with a set of customer machine parameters which principally provide a return path for the 

9 MDC script from the archive s^ce 15 to the customs 5. The customer machine 

1 0 parameter set preferably includes '^user agent" information, yMdi is the version of the 

1 1 customs browser 2&. 

12 At step 46, the arc^e service 15 generates a uidquetransactiori ID string and 

1 3 associates it with the customer machine parameter set in the MDAS archive 17. At step 

14 48, the archive s^ce returns the MDC script, with the transaction ID mbedded within 

15 it, to the customer browser 28. At step 50, the customer browser 28 processes the MDC 

1 6 soipt which, at a minimum, writes the transaction ID string into the merchant's transaction 

1 7 form. Assuming that the customer 5 completes the transaction and submits the transaction 

18 fomi to tiiemer<^ant 2 at step 52, the transaction n) string is stored with the tr^ 

19 data record 6 in the merchant transaction database 7. The transaction ID, thus, indirectiy 
2 0 assodates the machine data paramet^ set 18 stored in die MDAS archive 17 at st&p 54 

2 1 with fhe customer idratity information stored witii the transaction data record 6 in the 
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1 merchant's transaction database 7« Thereafter, qualified parties may access the MDAS 

2 archive 17 for information related to a transaction E>. 

3 The MDAS archive 17 need not contain any information which specifically 

4 identifies a particular customer, only the machme parameter profiles 18 with associated 

5 transaction ID strings. The MDAS archive records 18 can be analyzed in coiyunction vntii 

6 the merchant transaction records for patterns of fraud or for other purposes . The great 

7 majoiily of MDAS archive records can be puiged fix>m the archive 17 afi;er a selected 

8 period of time. Any records which are associated with any transaction irregularities or 

9 susjndons of actual ftmd may be retained longer. 

1 0 Fig. 5 illustrates the principal steps of a preferred embodiment 60 of the machine 

1 1 data collection and archiving process 1 of the present invention. The process 60 begins 

12 with the addition at 62 of a machine data collection (MDC) script to the transaction (TA) 

13 form page code ofa merchant web site 3. The fransaction form page code is processed at 

14 64 by a customer browser 28 when the lAerchant web page is accessed to thereby request 

15 the MDC script at 66 from the Machine data archive service (MDAS) web site 16. When 

16 the browser 28 accesses the MDAS web site 16, requesting the MDC script, the MDAS 

1 7 web site checks for the presence of an MDAS cookie at step 68. If no MDAS cookie is 

1 8 detected, an MDAS cookie is generated at 70 and a umque%ansaction identification 

1 9 (I A/ID) string is generated at 72. The MDC script,^ transaction ID, and cookie, if not 
2 0 previously set, are retumed at 74 to the customer browser 28, the transaction ID being 
21 embedded within the MDC script 
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When the MDC script is received by the browser 28, it is executed at 76. The 
cookie is stored in the cookie file 30, or possibly in the memory of the customer computer 
20. Execution of a prefen^ MDC script causes sev^al actions to be performed. The 
MDC script writes the transaction ID into the transaction fomi at step 78. The script can 
do this by either setting an existing variable of an appropriate name to the ti:ansaction ID 
string or by writing an appropriate variable mto the transaction fonn page and setting its 
value to the transaction ID strii^ Additionally, the preferred MDC scr^ generates a 
**fingerprinf ' of the customer computer 20 at step 80 and attempts to p^orm a proxy 
pierdng operation at step 82. 

In generating the machme fingerprint at 80, the MDC script queries the browser 28 
for a number of attributes and settings and concat^iates the results into an attribute string 
at84. The MDC script then perfonns a hashmg algorithm on the attribme string at 80 to 
g^erate a fingerprint string which has a hig^ degree of uniqueness. Hashing fimctions are 
urevei^le encryption processes m whidb the result is dependent on tiie original content of 
the data on which the hashing algorithm is operated. Hashing fiinctions are commonly 
used for data integrity checking. As previously stated, a common diecksum is the result 
ofatypeofhashmgfimction. The particular hashmgfimction employed prefer^ly 
maximizes the uniqueness of the resulting fiiigerprint 

At step 86, the customer computer clock 32 is queried for a current time value. At 
st^ 88, &e fingerprint, the transaction ID, and the time value are communicated to the 
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MDAS web site 16 along with an HTTP header with cookie and ""apparent" IP address, all 
of which are stored as 9 machine data profile 1.8 within the MDAS archive 17. 

At step 90, the MDC script adds a proxy piercer request to the transaction form 
which, when executed by the browser 28 at step 92, sends a request for a proxy piercer 
applet or code to the MDAS web site 16. When the proxy piercer applet/code is executed 
by the browser 28 at 94, a time value firom the clock 32 is agaki queried at 96 and any 
existing local area network (LAN) address is queried at 98. At step 100, Ike prosQr piercer 
applet/code sends the time value, the LAN address (if any), and the transaction ID to the 
MDAS web sate 16 by a protocol which bypasses any existing HTTP proxy 26. The 
protocol used is one which is at a low^ level than HTTP, such as UDP (usier datagram 
protocol) or, preferably, TCP/IP (transmission control protocol/internet protocol). 

Bypassing the HTTP proxy 26 causes the data sent in step 100 to anive at the 
MDAS web site 1 6 with the IP address of the primaiy gateway 22, which may be different 
firom any apparent IP address previously recorded if an HTTP proxy 26 intervenes. If ^e 
proxy piercer procedure 82 is successfiil, the primary gateway IP address is stored at step 
102 within the machine data profile 18 identified by the transaction ID. It should be noted 
that some types of proxies, such as some types of firewalls, may block all non-HTTP 
protocol packets, so that the proT^ piercer procedure 82 m^ht not be successfiil in all 
cases. 
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1 If the customer completes the transaction with the merchant web site 3, the 

2 transaction fonn is sub^iitted at step 104, which causes the transaction record 6, induding 

3 the transaction ID, to be stored at step 106 in the merchant database 7 for processing. 

4 Following are examples of code for an A4DC saipt, as fiom steps 40 or 62. 

5 Assuming the machine data archiving service or MDAS web site 16 has the fictional URL 

6 (unifonnresoun» locator) example-uri.net and a specific meixAant has a mercha^ 

7 identifier MMM, a line of HTML code is added at step 40 to the transaction fonn of 
merchant MMM between the <£om£> and <form> HTML tags vflach has the fonn: 

<SCTipt src^htlps://www.exampleHIri.net/s/?MM^C></script> 

When the customer browser 28 processes the transaction fonn at step 42, it 
requests a script file fiom the source URL: httDs:/Avww.example-iiri net/s/?MMM 

At step 44, the customer web browser 2B requests the MDC sci^ by w^ of the 
HTTPprotocoL The HTTP request includes the merchant ID MMM, the user agent 
(browser version), the IP address of the customer's HTTP proxy, and any HTTP cookies 
previously sent to the customer by www.example-url.net. Upon receiving this 
information, the ardiive service 16 records Has infonnatioil in a machine data record 
whidi also includes the transaction ID. 

Upon recdving the file request, the archive service 16 generates a unique 
transaction ID (represented below as ZZZ) at st^ 46 to be assodated with the transaction 
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1 and the machine parameter set. An ^emplaiy transaction ID is a string of 24 letters and 

2 digits. The first eight di^ts form a time-stamp which is a hexadecimal representation of 

3 tiie seconds elapsed since midnight January 1, 1970 UTG (coordinated universal time). 

4 In the preferred ^bodiment of the process 1, the MDC script is written in an 

5 ECMAScript compliant language, such as JavaSaipt, JScript, or VBSoipt A JavaScrqit 

6 veraon of the MDC script is as follows (Unebreaks and indentations added fi>r darity): 
7 

8 document.writeC'^iqmt name^^transactionid type^hidden value»ZZZ>; 

9 

10 (HiewDateO; 

11 

12 t==3600*d.gelHours(>+60*d.geliifinutes()+d.getSecondsO; 

13 

14 document.write(*<1nighdglrt=l widtii=l srcHit^sy/www.exan^le- 

15 uri.net/t/?i=ZZZ&t="+tf">"); 
16 

17 documentwrite("<appletheigJit^l width=l 

18 codd)ase^ittps://www.exampl©-url.net/ 

19 code=a/?ZZZ> 

2 0 <param namHl value=ZZZXapplet>"); 

21 
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The exemplary MDC script indudes the unique transactioii ID value in several 
places. When the script exewites on the customer computer 20, it writes HTML code into 
the merchant's order forin. Spedficalfy: 

1> The script adds a hidden variable called "transactionid" to the merchant's 
transaction form and assigns it the value of the transaction ID (ZZZ). When the 
transaction form is submitted, the merchant receives the transaction ID and can associate 
it with the transaction data record. 

2) TTie script computes the seconds elapsed since midnight on the clock 32 
and writes a request for a 1 pixel by 1 pixel unage. Included in the request is the 
transaction ID and the time value. When the request executes, this data is sent back to the 
archive service 16 and recorded with the transaction ID mtheMDAS archive 17. 

3) The script adds a request for a program located at the archive savice weh 
site 16 which, m this example, is a Java applet The applet downloads to the customer 
conq>uter 20 &om the ardiive service 16 and executes, appearing as a I pixel by 1 pixel 
image on the transaction form. The transaction ID is passed to the program as a 
parameter spedfied in the scaipt The program performs three ta^: 

a) it calculates TTT, the seconds elapsed smce midnight on the system clock 
32; 

b) it calculates AAA, the address of the customer 20 on its own local area 
netwoik24;and 
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1 c) it sends this data back to the archive service 16 via TCP/IP, by requesting 

2 the following UjEO.: 

3 http://ww.examDl&-tu-l.nP »/H/?i=777^ t=^rrT&ff='AAA 

4 The archive service 16 receives the message which includes the parameters TTT, 

5 AAA,andZZZ. The message also indudes the IP address of the sender. This address is 

6 the customer's actual IP address, which in some cases is differ^t from the HTTP proxy IP 

7 address. The archive service 16 records this information in the MDAS archive 17 and 

8 associates it with the transaction ID ZZZ. 

9 The machme data collection and archiving process 1 of the present invention has 

1 0 been described with a particular application in fraud detection. Ifowever, it is foreseen 

1 1 that the techniques of the present invention have a wider application, as for marketing or 

1 2 computer support purposes, or other functions. White the process 1 has been described 

1 3 with reference to the internet 4 or world wide web, it is also conceivable that the process 1 

1 4 could be employed on compute networks of less than global expanse, such as a laige 

1 5 intranet, a national or regional network, or the like. 

1 6 Therefore, it is to be und^stood tiiat while certain forms of the present invention 

1 7 have been illustrated and described herdn, the present invention is not mtended to be 

1 8 limited to the spedfic forms, arrangement of parts, sequence of steps, or particular 

1 9 applications described and shown. 
20 
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CLAIMS 

What is claimed and desired to secure by Letters Patent is: 
A process for collecting machine id^itifyiiig information associated vnth a distal 
online access device used for substantially anonymousfy accessing a host computer 
system over a digital network, said host computer system generating an interactioa 
record of an access therewith by said access device, and said process comprish^g 
the steps of: 

(a) capturing a machine identi^dng profile parameter iipon said access device 
accesaiig said host compute* system; 

(b) generating a unique interaction identification striog upon said access device 
accessiiig said host computer systoo^ 

(c) associating said interaction identification string with said profile parameter; 
and 

(d) assodatiiig said inteniction identification strii^ with said interaction record 
graerated upon said access device accessuig said host computer system. 

A process as set forth in Claim 1 wherein said capturing step includes the stq) of: 
(a) capturing a digtta] address ofsaid access de^ce on said digital network. ■ 

A process as set forth m Claim 1 wherdn said capturing step mcludes the step of 
(a) capturing a configuration siting of said access device. 
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4. A process as set forth in Claim 1 and including the steps of: 

(a) commuQicating a self-identification routine to said access device upon said 
access device acces^g said host computer system; 

(b) said access device executing said self-identification routine; 

(c) said self-identification routtne queiying a configuration setting of said 
access device to derive said profile parameter; and 

(d) said self-identification routine communicating said profile parameter to a 
remote location for assodation with said interaction identification string. 

5. A process as set forth in Claim 1 and including the steps of: 

(a) said host system operating a host web site including an interaction page 
generated by int^action page code processed by said access device upon 
accessing said host web site; and 

(b) coding, within said interaction page code, a sdf-identification routine 
which causes said access device to communicate said profile parameter 
when said access device processes said interaction page code. 

6. A process as set forth in Claim 3 and includmg the ^ep of: 

(a) codmg said self-id»tification routine in such a manner that said profile 
parameter and said interaction identification string are communicated to a 
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third party web site at which said profile parameter and said interaction 
idmtific^tion string are stored*. . 

A process for identi^g a customer computer involved in an online transaction 
between a customer using a customer browse opiating on said customer 
computer and a merchant operating a merchant web site, said method comprising 
the steps of: 

(a) capturing a customer computer profile parameter upon said customer 
computer accessing said merchant w^ site; 

(b) generating a transaction identification string and associating said string 
with said parameten 

(c) storing said parameter and said string in a machine data ardbive; 

(d) upon said customer completing a transaction through said merchant web 
site, storing said transaction identification string with a transaction record 
formed during said transaction to therelqr associate said parameter with 
said transaction record through said string. 

A process as set forth in Claim 7 wherein said captiiring step includes the step of: 
(a) capturing an IP address of said customs computer. 
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9. A process as set forth in Claim 7 wherein said capturing step includes the step of: 
(a) capturing a configuration setting of said customer computer. 

10. A process as set forth in Claim 7 and including the step of: 

(a) communicaling said profile parameter and said transaction identification 
string to a third party web site for storage. 

11. A process as set forth in Claim 7 and including the step of: 

(a) causing said customer computer to communicate said profile parameter and 
said transaction identification string to a tlurd party web site for storage. 

12. A process as set forth in Claim 7 and inchiding the steps of: 

(a) communicating a self«identification routine to said customer computer 
upon said customer computer accessing said merchant web ^e; 

(b) . said customer computer executing said self-identification routme; 

(c) said self-^identification routine querying a configuration setting of said 
customer computer to derive md profile paramet^; and 

(d) said self-identification routme communicatiiig said profile parameter to a 
remote location for association with said interaction identification string. 
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13^ .Apix>c^sassetfoitbinCluinl2aiidmcludiiigthest^Q£ 

(a) coding said self-identification routine in such a manner that said profile 
parameter and said int^ction identification string are communicated to a 
third party web site at which said profile parameter and said interaction 
identification string are stored. 

14. A process as set forth in Claim 12 wherem said querying step includes the steps of: 

(a) querying said customs browser for a plurality of configuration settings; 

(b) forming an attribute string fit>m said pluraliQr of configuration set^ 

(c) processing said attribute string to foim said profile parameter of said 
customer compute. 

15. A process as set forth in Claim 12 wherein said customer computer potentially 
accesses said merchant web site by way of a proxy^ and said commuoicadng step 
includes the steps of: 

(a) communicating said profile parameter and said transaction identification 
string to said rmote web site using a protocol which bypasses said pro3sy. 

16. A process for identi^dng a customer computer involved in an online transaction 
through a merchant web site between a customer usmg a customer browser 
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Operating on said customer computer and a merchant who operates said web site, 
said method comprising the steps of: 

(a) coding a script request within a transaction form of said merchant web site; 

(b) processing said script request by said customer browser upon accessing 
said merchant web site to thereby commimicate to an archiver web site of a 
machine data archiving sendee an electronic request for a machme data 
collection script; 

(c) said archiver web site returnmg said script to said customer browser along 
with a unique transaction identification string; 

(d) said customer browser processmg said script to thereby cause said script to 
query said customer computer for a profile parameter of said customer 
computet; 

(e) said script causing said customer browser to communicate smd profile 
parameter and said transaction identification string to said archiver web 
site; 

(£) said archiver web site storing said profile parameter and said transaction 
identification string in a machine data profile; 

(g) said script causing said customer browser tb write said transaction 
identification string into said transaction form; and 

(h) upon said customer adding customer identification information to said 
transaction form and electronical^ submittmg said transaction form to said 
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m^hant web site to thereby comprise a transaction record, said 
transaction identification- string associating said transaction record with said 
machine data profile. 

17. A process as set forth in Claim 16 and including the steps o£ 

(a) said script causmg said computer browser to communicate said profile 
parameter and said transaction idmtification string along with a 
conventional hypertext transfer protocol (HTTP) header; and 

(b) said archive service additionally storing said HTTP header in association 
witii said machine data profile. 

18. A process as set fi>rtfa in Claim 16 and inchidu^ the step o£ 

(a) said script querying said customer browser for a configuration setting 
thereof 

19. A process as set forth m Claim 16 and mcluding die steps o£ 

(a) said script querying said customer browser for a plurality of configuration 
settings; 

(b) said script formmg an attribute string firom said plurality of configuration 
settmgs; and . 
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(c) said script processing smd attribute string to fonn said profile parameter of 
said customer computer/ 

20. A process as set forth in Claim 19 wherein said script processing step includes the 
step of: 

(a) said script performing a hashing fimction on said attribute string to form 
said profile parameter. 

21. A process as set forth in Claim 16 wherein said customer computer pot^itially 
accesses said merchant wd) site by way of a proxy, and including the step of: 
(a) said script communicating said profile parameter and said transaction 

identification string to smd archiver s^ce web dte using a. protocol which 
bypasses said proxy. 

22. A process as set forth in Claim 16 and includiqg the step of: 

(a) said script communicating said profile parameter to said archiver service 
web site using a protocol other than HTTP. 

23. A process as set forth in Cl^ 16 \^erdn said customer computer includes a 
digital clock, and including the steps of: 
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(a) said script cau^ng said customer browser to query said dock for a time 
value; and 

(b) said script causing said customer browser to said said time value to said 
archiver service web site along with said profile parameter. 

A process for identi^g a customer compute- involved in an online traiKaction 
through a merchant web site betwe^ a customs- uang a customo- browser 
operating on said customer computer and a merchant who operates said web ate, 
said method comprismg the steps of! 

(a) coding a script request within a transaction form of said merdiant web site; 

0)) proces^g ssid saipt request by said customer browse upon accessmg 

said m^hant web site to therd}y communicate to an ardiiver web site of a 
madhine data archtving service an electronic request for a machine data 
collection soipt; 

(c) said aidiivra- web site returning smd script to said customer browser along 
with a unique transaction idoitification strii^ 

(d) said customer browser processing said script to thereby cause said script 
to: 

(1) queiy said customer browser for a plurality of conQguiarion 
settings; 

(2) foim an attribute string fiiom said plurality of configuration settmgs; 
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(3) perfonn a hashing &nction on said attribute string to fonn said 
profile parameter; and . 

(4) query an internal digital clock of said customer computer for a 
current time value; 

(e) said script causing said customer browser to communicate said profile 
paramet^, said time value^ and said transaction identification string to said 
archiver web site along with a conventional HTTP headei^ 

(f) said archiver web site storing said profile parameter, said time value, and 
said transaction identification string in a machine data profile; 

(g) said script causing said customer browser to write said transaction 
identification string into said transaction form; and 

(h) upon said customer adding customer identification information to said 
transaction form and electronically submitting said transaction form to said 
merchant web site to thereby comprise a transaction record, said 
transaction identification string associating said transaction record with said 
machine data profile. 

25. A process as set forth in Claim 24 wherein said customer computer potentially 
accesses said merchant web site by way of a proxy, and including the steps of: 
(a) said script querying said customer computer for a second profile parameter; 
and 



33 



01^7134 



PCTAJSOl/18076 



(b) said smpt commnmcadiig said second profile panmet^- and said 

transaction identification string to said archiver service web site using a 
protocol whick bypasses said proxy. 

A process as set forth in Claim 25 and inducing Ifae step o£ 
(a) said script communicating said second profile parameter to said sacctav& 
s^ce web ate u^ng a protocol other than HTTP. 
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